A CPU has a signal input named FLUSH# for flushing the internal cache system. The FLUSH# signal, when it is driven low by the system core, which controls and manages accessing to the memory, the CPU is forced to flush the entire contents of the on-chip cache. The CPU system is usually made up of a few components other than the CPU itself, for example, a main memory to store information and being accessed by the CPU to derive the data stored therein, a first cache memory which resides between the CPU and the main memory and provides a relatively very fast access to a required data and storing a flick portion of data which is occasionally accessed by the CPU and is duplicatedly stored in the main memory, and preferably a second cache which resides between the first cache memory and the main memory, which is not as fast as the first cache memory, but has an ability to store more data. The second cache memory also has a signal input line named FLUSH#, having similar purpose and function.
There are two ways for data write handling between the CPU and the secondary cache. One is write-through operation, which writes data to secondary cache and the main memory at the same time even if the CPU wanted the data to be written only into the secondary cache. The other is write-back operation, which only writes the data to the secondary cache when the CPU wanted the data to be written only into the secondary cache. In other words, there will be no back-up data in main memory in the case of write-back operation. As is easily imagined, the write-back operation is more efficient in view of data transfer, but it has a disadvantage that the contents of the secondary cache have to be transferred or "write-back" to the main memory at the occasion of cache flush for back-up purpose.
These components of the system are being connected by a common data transfer line called a CPU bus. Since the bus is common to all the components of the system, an access conflict may occur in the case of starting write-back cycles in response to FLUSH# signal. Therefore, an arbitration mechanism is needed to avoid this conflict. Before writing back the modified lines, the secondary cache must obtain ownership of the CPU bus in order to start write back cycle.
The CPU system typically mentioned herewith is shown in FIG. 1. In this figure, the first cache is included within the CPU and is not shown. The main memory is supposed to be connected to the secondary cache, but it is also not shown. The secondary cache is connected to both of the CPU and the system core by FLUSH#. The system core is a component which controls the input/output operation between the CPU, the secondary cache and the main memory. The FLUSH# provides the request to flush the first and secondary cache from the system core to the CPU. The CPU and the system core is connected via HOLD and HLDA. The HOLD is driven when the system core requests the CPU to release the bus. In turn, the CPU releases the bus after it has finished with the current tasks using bus, asserts HLDA# through HLDA to inform of the fact that the bus has been released. However, the secondary cache cannot obtain the ownership of the bus by itself in this system, since it can not transfer a signal to obtain the bus to the CPU nor the system core. This results into a conclusion that write-back operation can not be achieved in this system, because in order to achieve write-back operation, the secondary cache has to intensively obtain the ownership of the bus prior to starting write-back cycles.
This is the primary problem in the prior art. To solve this problem, BOFF# lines is added to the system. This line connects the secondary cache to the CPU, and when this is asserted, the CPU will instantly release the bus line, in turn the secondary cache obtains the ownership of the bus at the next CPU cycle. BOFF# forces the CPU to abort the current task and regenerate it later on from the first. However, this method may cause a problem if the secondary cache asserts BOFF# line while the CPU is working in a history sensitive manner. For example, if CPU is in a I/O cycle, the CPU should not cease its operation to release the bus because releasing bus in the midst of I/O operation, e.g. data transfer, will cause an inconsistency of the data, and even if the cycle is regenerated later, the inconsistency may not be recovered. It should be also noted that it is not possible for the secondary cache to detect whether the CPU is working in a history sensitive manner or not, nor selectively assert BOFF# in the timing window in which the CPU is not working in history sensitive manner.
Another way for obtaining the bus ownership for the secondary cache is to assert BOFF# when the CPU generates a dummy I/O cycle as shown in a document "Look-Aside Store In Cache Functional Specification, by Phil Milling and Jorge Lenta, Preliminary revision 1.1 (Jan, '93)". This method will solve the problem caused in the first way, since the secondary cache will go into the flush pending state when it detects the system core asserting FLUSH#. In this pending state, the secondary cache waits for a dummy I/O cycle, which the CPU is assumed to generate later. However, in this method, the flush cycle must be initiated by the CPU since the CPU has to generate the dummy I/O cycle, actually being stimulated by a system program. The program here is that it can not be applied to a system in which the system core initiates the flush.
One alternative for this method is to assert BOFF# when the CPU generates a flush acknowledge cycle. This method is, when the secondary cache detects the system core asserting FLUSH#, the secondary cache goes into the flush pending state and waits for the flush acknowledge cycle, which the CPU generates after it has completed the on-chip cache flush. But this method is inoperable to the type of the CPU that does not generates the flush acknowledge cycle. Actually, very limited types of the CPU generates flush acknowledge cycle, which implies that this method is not commonly processed in various systems.
Recently, many CPUs used in a personal computer (PC) system are applying a dual-mode memory management for application-transparent system services, such as power saving facility. For example, Intel x86 CPU chip adopts a mode which utilizes two apparently distinct memory systems having a common unique address for at least a portion of the entire address region. This means that a specific address corresponds to two different physical locations and either one of the two different physical location is defined by detecting the current mode of which the system runs. This additional mode is usually called a "system management mode" which is often abbreviated as SMM, on the contrary to the standard mode. When the system has to get into the SMM, the system core will interrupt normal program execution and invoke the SMM by generating a System Management Interrupt (SMI#) request to the CPU.
This dual mode system is schematically shown in FIG. 7. In this system, the operation is made in two modes of standard mode and system management mode, which is defined by SMIACT# generated by the CPU. For example, when the SMIACT# is driven high, the whole system is operated in the standard mode, which means that memory access will be made to standard RAM. In turn, when the SMIACT# is driven low, the whole system goes into the SMM, which means that memory access can be possibly made to the SMRAM. It should be noted, that in this FIG. 7, SMRAM exist in the range of logical address of 1000 to 2000, so an access to the address within this range will be made to the SMRAM and an access to the other memory address will be made to standard RAM, even if the whole system was operated in the SMM.
SMRAM is a physical memory dedicated for use by CPU while in the SMM, and having size of 32 KB to 4 GB, containing SMM handler codes, relevant system specific SMM data, and the processor state information representing the processor state prior to entering into the SMM. When the CPU enters into the SMM, it asserts SMIACT# low thus alerting the system core to switch into SMRAM space. The CPU then stores its current register state information into SMRAM in a stack-like fashion beginning at the top of the SMRAM space. This is referred to as the processor state dump, context switch or state save. Upon completion of the state save sequence, execution of the SMI handler will then begin. The CPU asserts the SMIACT# output to indicate to the memory controller that it is operating in SMM. The system logic should be ensured that only this area is being accessed by the CPU and SMI handler.
No existing system has allowed the system core to use FLUSH# for flushing a CPU-on-chip cache and a secondary cache both in the standard mode and the SMM. This is because the dual mode machines are previously not using write-back ways at the occasion of cache flush. But it is assumed that co-existence of dual mode and the write-back ways will upgrade the performance of personal computers, thus the cache flush problems with write-back and SMM has to be solved.
The request for cache flushing is frequently made when the CPU wants to switch the mode. Without any special effort, it is likely that the data consistency between the secondary cache and the main memory is violated, since SMIACT# is generated from the CPU almost at the same time with the actual cache flushing operation. This means that if SMIACT# is already generated and the system core has changed its memory bank one from the other (eg. SMRAM to standard RAM), the write-back from the cache memory will be made into wrong memory which the content of the cache memory did not originally belong.